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2 (U) Requirements 

2.1 (U) Overview 

1. (U//FOUO) Redacted. 

2. (U//FOUO) Cryptographic jargon is utilized throughout this document. This jargon has precise and 
subtle meaning and should not be interpreted without careful understanding of the subject matter. 
Suggested reading includes Practical Cryptography by Schneier and Ferguson, RFCs 4251 and 4253, 
RFCs 5246 and 5430, and Handbook of Applied Cryptography by Menezes, van Oorschot, and 
Vanstone. Special mention must be made of NIST SP 800-57-1 (draft May 2011 or later), which is a 
very thorough explanation of cryptosystem design details, ands its excellent discussion on security 
strength (generally half the shortest key length) and their expected lifetimes in Section 5.6. Further 
references are noted in the commentary section. 

3. (U//FOUO) These requirements bear intentional similarity to the National Security Agency's Suite B 
of Cryptographic Algorithms as well as industry best practice. 

4. (U//FOUO) Redacted. 

5. (U//FOUO) A tool satisfying all requirements of this document may be described as "Compliant with 
the Redacted Cryptographic Requirements version X" where X is the version number listed on the 
title page of this document. 

6. (U//FOUO) This document intentionally refers to non-embedded device software only. 

2.2 (U) Terminology 

1. (U) MUST - This word, or the term "SFIALL", means that the definition is an unconditional 
requirement of this specification. 

2. (U) MUST NOT - This phrase, or the phrase "SFIALL NOT", means that the definition is an 
unconditional prohibition of the specification. 

3. (U//FOUO) SHOULD - This word, or the adjective "RECOMMENDED", means that there may exist 
valid reasons in particular circumstances to ignore a particular item, but the full implications must 
be understood and carefully weighed before choosing a different course. The recommendations of 
this document outline options for increased security above and beyond the bare essential. The 
choices made in these items will be prime criteria for evaluation against competing solutions. Given 
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a hostile operating environment it is expected that more secure solutions will generally be 
preferred. 

4. (U//FOUO) SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that there may 
exist valid reasons in particular circumstances when the particular behavior is acceptable or even 
useful, but the full implications should be understood and the case carefully weighed before 
implementing any behavior described with this label. The recommendations of this document 
outline options for increased security above and beyond the bare essential. The choices made in 
these items will be prime criteria for evaluation against competing solutions. Given a hostile 
operating environment it is expected that more secure solutions will generally be preferred. 

5. (U) MAY - This word, or the adjective "OPTIONAL", means that an item is truly optional. 

6. (U//FOUO) TARGET - This word is used in reference to a deployed tool or implant executing on an 
untrusted or hostile device and communicating over an untrusted or hostile network. This word may 
also be used to refer to the untrusted or hostile device itself. Sponsor personnel will not have 
physical access to or control of items on the target. 

7. (U//FOUO) SERVER - This word is used in reference to sponsor controlled infrastructure or 
personnel. This word does not refer to intermediate nodes used for the purposes of redirection. 
Sponsor control does not indicate the absence of hostile implantation or exploitation; most server 
components will be exposed to hostile network connections and exploitation attempts and may be 
executing on hardware not under immediate sponsor supervision. Designs incorporating defense in 
depth are recommended. 

8. (U//FOUO) TRANSPORT - This word means the overt communication protocol being exercised 
between the target and the server. For example, HTTPS, SMTP, IMAP, Jabber, Skype. 

9. (U//FOUO) TRANSPORT ENCRYPTION - This phrase refers to the native encryption available for a 
transport where the use of that encryption with the transport protocol would be considered 
innocuous by the average observer (e.g., SSL/TLS for HTTPS, Encrypted Skype chat, SSL/TLS for 
secure Jabber, Encrypted RDP). This explicitly does not refer to any inner cryptostream compliant 
with the encryption suites as defined below. 

10. (U//FOUO) BLENDING - This word means the actions taken by the transport to assure passive or 
active observers of the benign nature of the communication, concealing its true purpose. 

11. (U//FOUO) TAKE - This word refers to all data collected from a target in the course of sponsor 
activities. All take is considered valuable until assessed otherwise and maximum care must be taken 
to preserve it. 
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2.3 (U) Changelog 

1. (U) Version 1.0 to 1.1 

a. (U//FOUO) Redacted. 

b. (U) 2.1: Created Overview section from bullets originally present in Terminology and section 
2.4. 

c. (U//FOUO) 2.2.11: Added "TAKE" to Terminology 

d. (U//FOUO) 2.4.15: Added PKCS #5 as a synonym for ANSI X.923 symmetric padding. 

e. (U//FOUO) 3.7, 4.7, 5.8: No longer discourage use of CBC mode. Though slightly inferior to 
other modes of operation it is widely available in standard APIs and encourages their use. 

f. (U//FOUO) Redacted. 

g. (U//FOUO) Added Portion marking. 

h. (U//FOUO) 2.2.6: Clarify the definition of "TARGET" to include interchangeable use of an 
implant and the computer hosting the implant. 

i. (U//FOUO) 2.4.19: Clarify that any use of transport encryption is layered over the encryption 
specified in this document. 

j. (U//FOUO) 2.1.6: Clarify this document does not refer to embedded devices or hardware 
implants. 

k. (U//FOUO) 8.i: Clarify some reasons asymmetric cryptography is so pervasive in this 
document. 

l. (U//FOUO) 2.4.16: Prohibit the use of PKCS #lvl.5 asymmetric padding. 

m. (U//FOUO) 3.1, 4.1, 5.1: Clarify that Diffie-Flellman and RSA must have larger keys than 
ECDH. 

n. (U//FOUO) 3.1, 4.1, 5.1: Clarify that Diffie-Flellman alone does not provide perfect forward 
secrecy. 

o. (U//FOUO) 2.1.7: Added bullet clarifying the nature of the classification of this document 
and acceptable means to lower the classification. 


2.4 (U/ /FOUO) Tools with initial delivery 1 January 2012 or later 

5 


UNCLASSIFIED/ /FOUO 



UNCLASSIFIED/ /FOUO 


1. (U//FOUO) All tools utilizing network communication must implement either the Long-lived, Short- 
lived, or Collection Encryption Suite of cryptographic algorithms as defined below. A tool's author 
must implement the appropriate suite for the tool's Concept of Operation (CONOP). 1 

2. (U//FOUO) All tools should implement the Tool State Encryption Suite in reference to configurable 
state (e.g., callback addresses, intervals, subsequent persistent cryptographic keys). Tool authors 
may extend the implementation of the Tool State Encryption Suite to tool components (e.g., code 
blocks, packaged components within an installer) but must carefully consider and evaluate the 
impact on PSP performance. 

3. (U//FOUO) All cached or otherwise stored take which has not yet been transferred to server and is 
not stored in RAM should be protected using the Collection Encryption Suite. 

4. (U//FOUO) Communications involving only file exchange (e.g., an automated implant collecting 
tasking or submitting tasking results) must encrypt the exchanged file using the Collection 
Encryption Suite. This encryption must be separate from and additional to any transport encryption. 
Such communications may incorporate either the Long-lived or Short-lived Suites. 

5. (U//FOUO) All tools must utilize Operating System (OS) provided cryptographic primitives where 
available (e.g., Microsoft CryptoAPI-NG, OpenSSL, PolarSSL, GnuTLS, etc). Note the guidance in the 
relevant encryption suites regarding suitable Certificate Authorities (CAs) for each phase of 
communication. Deviations must be justified and accepted by the OCRB." 

6. (U//FOUO) All tools must utilize OS provided cryptographically secure sources of entropy (e.g., 
/dev/random on *nix, Microsoft CryptoAPI, etc) and should be a source compliant with NIST SP 800- 
90. If a non-800-90 mechanism is used, the output from the source of entropy must be hashed with 
SFIA-256 prior to use. Deviations from this must be justified and accepted by the OCRB. 1 " 

7. (U//FOUO) All message digests must be performed using SFIA-256, SFIA-384, or SFIA-512 without 
truncation. HMACs must be performed using HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512 
without truncation. IV Digests and FIMACs must be computed over the ciphertext (to include 
Initialization Vectors) of each message vice the plaintext/ 

8. (U) Asymmetric cryptography must not be used directly for bulk encryption. It must only be used to 
negotiate or exchange secrets used for symmetric encryption and for digital signatures and their 
verification/ 1 

9. (U//FOUO) Communication adhering to these requirements involves multiple cryptographic keys, 
whether used for encryption, authentication, or integrity checking. All entropy used for key material 
(including components of key exchange) must be generated using a source of randomness as 
defined in 6 above. Keys should be generated independently where possible but may be derived 
from an exchanged secret using Key Derivation Functions (KDFs) approved by NIST SP 800-108 
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(October 2009) and NIST SP 800-56C (second draft July 2011) or later revisions. VM If such a KDF is 
chosen then the exchanged secret must have a length equal to sum of the lengths for all needed key 
material (e.g., 512 bits if two 256 bit keys are required). Vl " The guidance regarding hashing algorithm 
selection in 7 above applies to the hashing algorithms chosen for use with the KDF. 

10. (U//FOUO) Messages should be compressed prior to encryption. IX Compression must be performed 
using appropriate domain-specific compression (e.g., MP3 for audio, BZIP2, GZIP, ZUB, or raw 
DEFLATE for arbitrary data)/ Compression should be performed using OS provided APIs/ 1 Authority 
to determine whether a compression routine is considered appropriate for a domain rests with the 
OCRB. 

11. (U//FOUO) For pseudo One Time Pad ciphers and block modes (i.e., RC4, CTR, GCM), all 
communication from target to server must use distinct encryption keys from those used for server 
to target/" 

12. (U//FOUO) Tools should perform key exchange exactly once per connection. The volume of data 
expected during a given connection does not meet the threshold where a re-key is required/ 1 " To 
reiterate, re-keying is not recommended. 

13. (U//FOUO) To guard against replay attacks every message sent must employ a nonce scheme. 
Nonces should take the form of monotonic message numbers and, if so, must track message 
numbers from each party separately. Alternatively, nonce schemes may use a timestamp easily 
converted to a full UTC date and time but due to the difficulty in ensuring close time synchronization 
when messages are frequent, timestamps are not recommended. Nonce values must not be 
repeated for the same encryption key and authentication key combination. 

14. (U//FOUO) For CBC mode all Initialization Vectors (IVs) must be strong pseudorandomly generated, 
randomly generated as in 6 above, or generated using a KDF as permitted in 9 above/' v For CTR and 
GCM mode, all IVs should start from zero and should use strong pseudorandom or random fixed 
field prefix padding to bring the counter value up to the minimum length.” All IVs must have a 
minimum length of one block of the chosen cipher.™ IVs must not be reused with the same 
encryption key.™" 

15. (U//FOUO) Padding for symmetric encryption, when required by the chosen cipher and mode, must 
be performed using either the PKCS #7 or ANSI X.923/PKCS #5 padding techniques.™ 1 " Padding must 
be applied after any compression but before any encryption. 

16. (U//FOUO) Padding for asymmetric encryption, when required, must not be performed using the 
PKCS #lvl.5 padding scheme 1 ™. OAEP padding is recommended. 

17. (U//FOUO) Proper key management must be carefully considered by tool authors to ensure that 
each deployed tool utilizes unique persistent keys (including unique server keys where appropriate). 
Authors must submit a key management plan outlining the mechanisms used to ensure uniqueness 
properties, proper usage, and archiving of all keys on a classified sponsor network. 
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18. (U//FOUO) Tool authors must submit a cryptographic design document for approval to the OCRB. 
This document must contain sufficient information regarding the tools use and handling of the 
concepts discussed in these requirements to convince them that the design is secure. Specifically, 
this document must discuss key management (authors may reference their key management plan), 
IV selection, algorithm selection, message format (as it pertains to the cryptographic details), 
frequency of messages, error/failure handling, authentication, key exchange, integrity assurances, 
and similar details. Authors should expect that this design will be reviewed by other entities within 
the US Government while respecting Proprietary Information controls. Submission of this document 
early in the development cycle is recommended. A cryptographic design approval is valid for a single 
tool and remains valid until and unless authors undertake substantive changes in the use of 
cryptography or until the approval is revoked. 

19. (U//FOUO) These cryptographic suites are intended to protect the innermost layer of 
communication. It is expected and encouraged that transport protocol standards will additionally 
encrypt traffic exchanged via that transport as appropriate (e.g., FITTP over TCP port 80 should not 
be overtly encrypted but FITTPS over TCP port 443 should be).Any transport layer encryption must 
be layered over the cryptography discussed in this document. Because this outer layer may be 
decrypted by an attacker (e.g., SSL Man-in-the-Middle) any transport encryption must be used for 
traffic blending only and not for secrecy. ** 

20. (U//FOUO) The Operational Cryptography Review Board (OCRB) must approve all deviations from 
these requirements. 


2.5 (U/ /FOUO) Tools with initial delivery prior to 1 January 2012 

1. (U//FOUO) Existing tools must implement all requirements for new tools as above. 

2. (U//FOUO) Optionally, existing tools may implement the Weak Suite instead of the Long-lived or 
Short-lived Suite of cryptographic algorithms as defined below. Tools which utilize the Weak Suite 
should plan to become compliant with either the Long-lived or Short-lived Suites. 

3. (U//FOUO) Approval of cryptographic design and key management plan is recommended but not 
mandatory. 
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3 (U//FOUO) The Long-lived Suite for Network Communication 


(U//FOUO) The Long-lived Suite of algorithms is intended for use with tools residing on a target or 
redirector for longer than one working day but may be used by tools with shorter expected lifetimes. In 
general the structure of the Long-lived Suite is similar to that of a TLS 1.2 handshake with client 
authentication, specifically in the use of asymmetric cryptography to provide authentication and key 
exchange followed by communication utilizing symmetric cryptographic primitives together with the 
exchanged secrets to provide confidentiality and integrity. The inclusion of TLS 1.2 in this suite does not 
imply that a protocol adhering to this suite may be described as "SSL" or "HTTPS". 

1. (U//FOUO) Key exchange must be performed using Diffie-Hellman, Elliptic Curve Diffie-Hellman, or 
RSA. For Elliptic Curve Diffie-Hellman the prime moduli utilized must be at least 256 bits. For Diffie- 
Hellman and RSA the primes utilized must be at least 2048 bits. The use of Diffie-Hellman or Elliptic 
Curve Diffie-Hellman is recommended to allow for perfect forward secrecy. 

2. (U//FOUO) Authentication must be performed using TLS 1.2, Elliptic Curve DSA, DSA, or RSA. 
Asymmetric keys must be at least 2048 bits (256 bits for elliptic curve prime moduli). 

3. (U//FOUO) Authentication via TLS 1.2 must include the use of certificates by both parties. 

4. (U//FOUO) Authentication via TLS 1.2 must validate that the certificate utilized by both parties 
match preshared certificates or a preshared CA. Should validation of either party fail, the other 
should terminate the connection but the termination decision may rest with the server component 
alone. Certificate validation must not be performed against any standard SSL root CAs. Note that 
this guidance refers to the inner cryptostream which may optionally be masked by HTTPS (or some 
other outer transport protocol), this does not refer to the certificates or encryption used by the 
outer blending channel. 

5. (U//FOUO) Tools must support the use of unique certificates and CAs for network authentication for 
each deployment or group of deployments (e.g., through Server Name Identification (SNI) extension 
for TLS). 

6. (U//FOUO) Integrity must be provided using HMAC with a key size of at least 256 bits. 

7. (U//FOUO) Confidentiality must be provided by AES with a minimum key size of 256 bits. The cipher 
must be operated in Galois/Counter Mode (GCM), Counter Mode (CTR), or Cipher Block Chaining 
Mode (CBC). 
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4 (U//FOUO) The Short-lived Suite for Network Communication 


(U//FOUO) The Short-lived Suite of algorithms is intended for use with tools residing on a target or 

redirector for less than one working day. Asymmetric cryptography is utilized to a lesser degree by the 

Short-lived Suite because the CONOP for the suite implies a far greater control of the tool by an 

operator and a lower risk of exposure to hostile actors. 

1. (U//FOUO) Key exchange must be performed using Diffie-Flellman, Elliptic Curve Diffie-Flellman, or 
RSA. For Elliptic Curve Diffie-Flellman the prime moduli utilized must be at least 256 bits. For Diffie- 
Flellman and RSA the primes utilized must be at least 2048 bits. The use of Diffie-Flellman or Elliptic 
Curve Diffie-Flellman is recommended to allow for perfect forward secrecy. 

2. (U//FOUO) Authentication must be provided using FIMAC, asymmetric cryptography, or by 
operating the chosen block cipher in Gaolis/Counter Mode (GCM). 

3. (U//FOUO) Authentication using FIMAC must use a key size of at least 256 bits. The key must be 
preshared and must not be reused for any other deployment. 

4. (U//FOUO) Authentication using asymmetric cryptography must be provided using TLS 1.2, Elliptic 
Curve DSA, DSA, or RSA using asymmetric keys of at least 2048 bits (256 bits for elliptic curve prime 
moduli). All authentication based on certificates and CAs must follow the requirements concerning 
certificates and CAs described in the Long-lived Suite paragraphs 4, and 5. 

5. (U//FOUO) Integrity must be provided using FIMAC with a key size of at least 256 bits. 

6. (U//FOUO) Authentication and Integrity FIMACs may be one and the same if FIMAC is used for 
authentication. 

7. (U//FOUO) Confidentiality must be provided by AES with a minimum key size of 256 bits. The cipher 
must be operated in Galois/Counter Mode (GCM), Counter Mode (CTR), or Cipher Block Chaining 
Mode (CBC). 
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5 (U//FOUO) The Weak Suite for Network Communication 

(U//FOUO) The Weak Suite is intended as a transition suite and must not be used for new tools. 
As the name implies, it provides reduced security compared to the other suites. Tools utilizing this suite 
should plan to transition to either the Long-lived or Short-lived Suites to facilitate deliveries once the 
Weak Suite has been retired. The Weak Suite shall be retired on 31 December 2013 and shall not be 
used for deliveries after that time. This date complies with NIST Special Publication 800-131A regarding 
protection of unclassified data for US Government systems. 

1. (U//FOUO) Key exchange must be performed using Diffie-Flellman, Elliptic Curve Diffie-Flellman, or 
RSA. For Elliptic Curve Diffie-Flellman the prime moduli utilized must be at least 128 bits. For Diffie- 
Flellman and RSA the primes utilized must be at least 1024 bits. The use of Diffie-Flellman or Elliptic 
Curve Diffie-Flellman is recommended to allow for perfect forward secrecy. 

2. (U//FOUO) Authentication must be provided using FIMAC, asymmetric cryptography, or by 
operating the chosen block cipher in Gaolis/Counter Mode (GCM). 

3. (U//FOUO) Authentication using FIMAC (which may include FIMAC-SFIA1) must use a key size of at 
least 128 bits. The key must be preshared and must not be reused for any other deployment. 

4. (U//FOUO) Authentication using asymmetric cryptography must be provided using TLS 1.2, Elliptic 
Curve DSA, DSA, or RSA with asymmetric keys of at least 1024 bits (128 bits for elliptic curve prime 
moduli). All certificate and CA handling instructions and requirements from the Long-lived Suite 
must also be applied. 

5. (U//FOUO) Authentication using GCM mode must use a tag length of 128. The author must carefully 
consider NIST SP 800-38D (November 2007), especially the peculiarities described in Appendixes A 
and B. 

6. (U//FOUO) Integrity must be provided using FIMAC (which may include FIMAC-SFIA1) with a key size 
of at least 128 bits. Alternatively, integrity may be provided by using Elliptic Curve DSA, DSA, or RSA 
signatures on message digests. The certificates used to generate these signatures must either be 
preshared or utilize a preshared CA and must have a key size of at least 1024 bits (128 bits for 
elliptic curve prime moduli). 

7. (U//FOUO) Authentication and Integrity FIMACs may be one and the same if FIMAC is chosen for 
both. 

8. (U//FOUO) Confidentiality must be provided by AES, Serpent, Twofish, Blowfish, 3DES, or RC4 with a 
minimum key size of 128 bits. Block ciphers must be operated in Galois/Counter Mode (GCM), 
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Counter Mode (CTR), or Cipher Block Chaining Mode (CBC). If RC4 is used, at least the first 1024 
bytes of the cryptostream must be discarded and may not be used.™ AES is recommended due to 
hardware implementations by major CPU vendors and to enable transition to a more secure suite. 

9. (U//FOUO) Redacted. 

6 (U//FOUO) The Collection Encryption Suite 

(U//FOUO) The Collection Encryption Suite is intended to safeguard collected information as it 
resides temporarily on an untrusted file system or as it transits a file-oriented communication 
mechanism (e.g., gap jumpers, bit torrent, HTTP post, etc.). This suite is primarily intended for 
Automated Implants and collection tools but may be applied by other tools utilizing file-oriented 
transports. Note that the Collection Encryption Suite is intended for files generated by a tool for transfer 
to server and for tasking from server to target, for encryption of data referenced repeatedly by a tool 
utilize the Tool State Encryption Suite. Like the Long-lived Suite this also resembles TLS 1.2 except that 
the Collection Encryption Suite protects a communication in time rather than an interactive 
communication. 

1. (U//FOUO) Authentication and Integrity must be provided by a signed message digest. The message 
digest must be calculated over the encrypted file. The results of the calculated message digest must 
then be signed using the sender's preshared asymmetric private key and attached to the encrypted 
blob (e.g., appended, prepended, etc). 

2. (U//FOUO) Confidentiality must be provided by AES with a key size of at least 256 bits. The cipher 
must be operated in Galois/Counter Mode (GCM), Counter Mode (CTR), or Cipher Block Chaining 
Mode (CBC). 

3. (U//FOUO) For each transmission the encrypting session key shall be generated randomly by the 
sender and used to encrypt the file. The session key shall then be encrypted to the recipient's 
preshared asymmetric public key and attached to the encrypted blob (e.g., appended, prepended, 
etc). 

4. (U//FOUO) All asymmetric keys used in this suite must have a length of at least 2048 bits (256 bits 
for elliptic curve prime moduli).™ 1 
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7 (U//FOUO) The Tool State Encryption Suite 

(U//FOUO) The Tool State Encryption Suite is intended to safeguard tool components, state, and 
working data that is unsuited for or not ready to be transferred to the server as it resides on an 
untrusted file system or other persistent storage. 

1. (U//FOUO) Integrity must be provided by FIMAC with a key size of at least 256 bits. 

2. (U//FOUO) Confidentiality must be provided by AES with a key size of at least 256 bits. The cipher 
must be operated in Galois/Counter Mode (GCM), Counter Mode (CTR), or Cipher Block Chaining 
Mode (CBC). 

3. (U//FOUO) Optionally a tool may verify a digital signature on a message digest calculated over the 
encrypted form of the relevant state. The signing private key for this purpose must only exist on a 
sponsor classified network and must have a length of at least 2048 bits (256 bits for elliptic curve 
prime moduli) while the relevant public key shall be stored on the target. Consequently this 
additional authentication can only verify certain static or default components or states. 

4. (U//FOUO) There is additional risk to the stored data because of the need for the target component 
of the tool to decrypt the stored state. Consequently tool authors should carefully consider key 
management on the target, this must include any authentication and integrity keys in addition to 
the encryption key. 1 ™" 
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8 (U) Commentary 


1 (U//FOUO) In particular, asymmetric cryptography is heavily use to limit the utility of previously 
captured network transmissions by preventing decryption even after reverse engineering the implant 
and to minimize the data encrypted with any particular key material. 

" (U//FOUO) In particular, the justification that an attacker might hook the OS provided cryptographic 
API to perform reverse engineering of the implant is not acceptable; any service (including execution) 
provided by the OS may be subverted and the security of a proven library outweighs the risk of attack. 

(U//FOUO) A special note for tools targeting versions of Microsoft Windows prior to Vista: the Microsoft 
CryptoAPI (as distinct from the Microsoft CryptoAPI-NG) does not offer all the cryptographic primitives 
required by this document. Specifically the Microsoft Enhanced Cryptographic Provider does not provide 
the message digest algorithms required in 7. These algorithms were added in the Microsoft Enhanced 
RSA and AES Cryptographic Provider (Prototype) bundled with Windows XP SP3. This module, renamed 
Microsoft AES Cryptographic Provider, is also available as an optional hotfix for Windows 2003. Tools 
which must support Windows 2003 or Windows XP SP2 and below should statically link an 
implementation of the necessary primitives from OpenSSL or similar library but may implement these 
primitives. 

(U) Insecure sources of entropy can lead to unacceptably poor quality cryptographic keys and 
therefore total cryptosystem compromise. 

NIST Special Publication 800-90: Recommendation for Random Number Generation Using Deterministic 
Random Bit Generators (Revised March 2007). http://csrc.nist.gov/publications/nistpubs/800-90/SP80Q- 
90revised March2007.pdf 

IV (U) The use of SHA-1 has been deprecated for digital signature purposes after December 31, 2010. 
Though other uses remain acceptable we have chosen to eliminate its use entirely in the interests of 
simplicity of implementation by not introducing multiple hash mechanisms within a project and for ease 
of assuring the desired security level. 

NIST Special Publication 800-131A: Transitions: Recommendation for Transitioning the Use of 
Cryptographic Algorithms and Key Lengths (January 2011). 
http://csrc.nist.gov/publications/nistpubs/800-131A/sp80Q-131A.pdf 

v (U//FOUO) The digest is calculated over the ciphertext vice plaintext in order to protect against a 
SIGINT actor with access to a compromised host obtaining any information about the transfer. Using the 
example of an exfiltrated file (and depending on communication protocols) it is possible that a SIGINT 
actor could compare the hash value of every file on the compromised host to the intercepted message 
and thereby determine which file was exfiltrated. Calculating the digest over the ciphertext eliminates 
this possible information leakage without altering difficulty of implementation. See also the various 


UNCLASSIFIED/ /FOUO 


UNCLASSIFIED/ /FOUO 


debates about Encrypt-and-MAC, MAC-then-Encrypt, and Encrypt-then-MAC. The IV is authenticated by 
the digest in order to prevent a manipulated IV from flipping bits in the first block of the plaintext upon 
decryption under certain modes. 

Vl (U) Asymmetric cryptography is significantly more computationally expensive than symmetric. 
Additionally, limiting the use of asymmetric keys in this way also reduces the amount of data encrypted 
with any given key and consequently makes cryptanalysis much more difficult. 

Menezes, van Oorschot, and Vanstone. Handbook of Applied Cryptography (August 2001). Chapter 12. 

v " (U) Independent generation of keys provides the maximum protection from related key attacks and 
implementation errors. It is, however, more difficult to implement and more wasteful of entropy and 
require more network messages than the use of a KDF. 

NIST Special Publication 800-108: Recommendation for Key Derivation Using Pseudorandom Functions 
(Revised October 2009) 

http://csrc.nist.gov/publications/nistpubs/800-108/sp80Q-108.pdf 

Vl " (U) This maximizes entropy in the derived keys. 

NIST Special Publication 800-108: Recommendation for Key Derivation Using Pseudorandom Functions 
(Revised October 2009) Section 7.3. 

http://csrc.nist.gov/publications/nistpubs/800-108/sp80Q-108.pdf 

lx (U) Compression reduces the amount of information to be encrypted, thereby decreasing the amount 
of material available for cryptanalysis. Additionally, compression is designed to eliminate redundancies 
in the message, further complicating cryptanalysis. 

x (U) Domain specific compression is utilized to maximize compression ratio. 

Xl (U//FOUO) OS provided compression routines are recommended to ensure correctness without an 
increase in code size. 

x " (U) As a property of the way these cryptographic algorithms are implemented an adversary can XOR 
two ciphertexts encrypted with the same key in order to obtain the XOR of the two plaintexts, thereby 
destroying most or all confidentiality. 

Xl " (U//FOUO) The utility inherent in re-keying derives from minimizing key exposure when performing 
bulk encryption of large amounts of data. Even the most data-intensive sponsor operations involve 
several fewer orders of magnitude of data per session key. Consequently, re-keying introduces 
unnecessary complexity (and therefore opportunities for bugs or other unexpected behavior) without 
delivering value in return. 

XIV (U) This avoids a number of attacks inherent in CBC. The key property to these attacks is that the IV be 
unpredictable and, in the interests of not exhausting the target's entropy pool we permit pseudorandom 
generation of this value. 
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Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures. 2004-05-20. 
http://www.openssl.org/~bodo/tls-cbc.txt 

xv (U//FOUO) The additional entropy from the tag prefix is used as a simple to implement mechanism to 
make IV/session key collisions even rarer than^/ 2 2 56 - Though selecting an initial counter value 
randomly also increases the odds of a collision it also introduces difficulties in exchanging initial value 
and determining whether a counter sequence under the same key will overlap with a different counter 
sequence. 

XVI (U) This substantially increases the difficulty of pre-computing the IV, thereby protecting against 
certain chosen plaintext attacks. 

xv " (U) Reusing IVs under the same encryption key significantly reduces, and for some modes destroys, 
confidentiality. 

XVI " (U) These techniques are simple to implement and ensure no confusion about padding values versus 
message values. 

XIX (U) Bleichenbacher, Chosen Ciphertext Attacks against Protocols Based on the RSA Encryption 
Standard PKCS#1, 1998 

Bleichenbacher, Kaliski, and Staddon, Recent results on PKCS#1: RSA Encryption Standard, 1998. 

xx (U//FOUO) To reiterate using an example: An implant named X communicates using files sent over 
FITTPS GETs and POSTs. To be compliant with this document, X must ensure that the files transferred are 
compliant with the Collection Encryption Suite and the SSL handshake conducted with the listening post 
is conducted as defined in the FITTPS standard and authenticated against a standard set of root CAs. 

(U//FOUO) The SSL tunnel X is using to communicate with server might be subject to an SSL MitM 
attack, potentially using a CA issued "valid" certificate. Because X utilized the Collection Encryption Suite 
the take would not be compromised however this sort of interception would permit an adversary 
greater insight into sponsor activities and facilitate more detailed traffic analysis as well as serve as a 
possible avenue of denial of service whereby X believes it has correctly communicated with server and 
therefore might not engage appropriate fallback behavior (e.g., uninstall, change beacon domain, etc.). 
To provide greater security against such an attack, X may go further than required and implement an 
inner cryptostream within the SSL tunnel transfer compliant with the Long-lived Suite. In this way X can 
ensure that it is delivering the raw intelligence only to a server component despite the presence of an 
active attacker. This makes tool X very valuable in those countries known to routinely MitM SSL (e.g., 
China, Iran). 

XXI (U) RC4 has key scheduling flaws which can reveal the secret key under certain circumstances. This 
countermeasure makes most of those circumstances much more difficult. 
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Fluhrer, Mantin, and Shamir. Weaknesses in the Key Scheduling Algorithm of RC4. Proceedings of the 4 th 
Annual Workshop on Selected Areas of Cryptography, 2001. 

xx " (U//FOUO) Note that there are two key pairs for a total of four asymmetric keys utilized in this Suite: 
Server Pub | ic (utilized and stored on the target), Server Private (utilized and stored only on classified sponsor 
networks), Target Pu bii C (utilized by server, no copy needed on the target), and Target Priva te (utilized and 
stored on the target) 

XXI " (U//FOUO) One novel technique seen in the wild and provided purely as an example of a clever 
solution is the Random Decryption Algorithm (RDA) technique whereby a piece of malware does not 
possess the decryption key for its own main execution component. This malware is designed to brute 
force the decryption key, a process that can take several hours on modern hardware and has the added 
benefit of extreme resiliency to polymorphic detection heuristics and static scanning. Authors who 
believe they have a particularly novel approach are encouraged to contact the OCRB for a detailed 
discussion. 
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